حتما در خصوص RODC مطالعاتی داشته اید و ممکن است هر کس از شما سئوال بکند بگویید که RODC مخفف کلمه های Read Only Domain Controller یا Domain Controller فقط خواندنی است و معمولا این برداشت می شود که این یک کپی کامل ولی خواندنی از پایگاه داده اکتیودایرکتوری شما است که در سایت های مختلف شبکه خودتان قرار می دهد. این موضوع بارها در انجمن تخصصی فناوری اطلاعات ایران مطرح شده است و به همین دلیل امروز تصمیم گرفتم در خصوص نحوه عملکرد RODC در شبکه برای شما مقاله ای بنویسم. طبیعتا زمانیکه صحبت از RODC می شود شما از آن در شعبه ها یا نمایندگی های شرکت یا سازمان خود می خواهید استفاده کنید تا کاربران آن شبکه بتوانند به راحتی به سیستم ها و سرویس های مورد نیاز شبکه Login کنند. اما آیا تا به حال به این موضوع فکر کرده اید که چه فرآیندی بر روی RODC انجام می شود که باعث احراز هویت شدن یا Authenticate شدن کاربران می شود ؟ این خیلی مهم است که در زمان استفاده از RODC درست متوجه بشویم که Authentication چگونه انجام می شود.

اول از همه یک نکته را در نظر داشته باشید که در RODC هیچ پسوردی بصورت پیشفرض ذخیره نشده است و به همین خاطر نباید نگران به سرقت رفتن اطلاعات موجود در آن باشید ، البته این یک فرضیه است. قبل از هرگونه توضیحی این موضوع را هم فراموش نکنید که تمام نیاز کاربران شما در شعبه ها و نمایندگی های شما فقط Login کردن داخل سیستم نیست و شما باید بدانید که احراز هویت توسط پروتکل Kerberos انجام می شود که پروتکل احراز هویت پیشفرض اکتیودایرکتوری است. در دنیای Kerberos چند قانون اصلی وجود دارد ، مهمترین قانون در Kerberos این است که اگر شما Ticket احراز هویت نداشته باشید ، بنابراین احراز هویت هم نمی شوید و دسترسی ها برای شما باز نخواهند شد.شما از Kerberos برای همه سرویس های دامین استفاده می کنید ، برای انجام برخی کارها حتی کامپیوترها نیز در اکتیودایرکتوری بایستی احراز هویت شوند چه برسد به کاربران ، بنابراین بسیار ضروری و الزامی است که شما سیستم احراز هویتی خودتان را که در دفتر مرکزی دارید در شعبه ها و نمایندگی ها هم داشته باشید و از همه مهمتر شما باید سیستمی داشته باشید که حتی در صورت از بین رفتن لینک و ارتباط بین دفتر اصلی و شعبه یا نمایندگی ، همچنان بتواند احراز هویت کاربران را نیز انجام بدهد.

طبیعی است که شما هیچوقت ریسک قرار دادن کل Domain Controller خودتان به عنوان یک DC خواندنی نوشتنی در شعبه ای که بعضا کارشناس فنی هم ندارد را انجام نمی دهد. در اینجاست که شما از مکانیزمی باید استفاده کنید که ضمن اینکه احراز هویت را بتواند بصورت Offline و از طریق نام کاربری و رمز عبور Cache شده انجام دهد بتواند ریسک امنیتی شما را نیز به حداقل برساند. شما در چنین مواردی از RODC استفاده می کنید. خوب حالا ما می خواهیم یک سناریو برای شما مثال بزنیم ، فرض کنیم که انجمن تخصصی فناوری اطلاعات ایران دارای یک مرکز اصلی یا Headquarter در کرج است و در تهران هم یک شعبه دارد که تعدادی کاربر در تهران مشغول به فعالیت هستند ، می خواهیم بدانیم که وقتی یک ماشین در شبکه شعبه تهران روشن می شود و می خواهد به یک فایل سرور که در شبکه همان شعبه قرار دارد متصل شود که در همان سایت قرار دارد چه اتفاقی می افتد ؟ در این سناریو ما فرض را بر این گذاشته ایم که کاربر ما برای اولین بار در شبکه شعبه تهران می خواهد از RODC برای Login کردن به شبکه استفاده کند و در حال حاضر هیچ پسوردی در RODC بصورت Cache شدن نگهداری نمی شود. ما سعی می کنیم مطالب را بصورت ساده بیان کنیم هر چند ساختار احراز هویت در اکتیودایرکتوری اصلا ساده نیست ولی ما می خواهیم تا جای ممکن این فرآیند را برای شما ساده سازی کنیم.

احراز هویت ماشین ها و کاربران در RODC چگونه انجام می شود ؟
مکانیزم احراز هویت ماشین ها و کاربران در اکتیودایرکتوری تا حدود زیادی شبیه به هم و یکسان است. کلاینت ها از طریق DNS سرور و فرآیند DCLocator متوجه می شود که که سرور RODC ای که در همان سایت وجود دارد عملیات احراز هویت را باید اتجام دهد و در اصطلاح فنی تر DCLocator تشخیص می دهد که RODC وظیفه Authoritative Authentication را بر عهده دارد. همانطور که در تصویر زیر مشاهده می کنید در اولین گام کلاینت درخواست احراز هویت خودش را به سمت سرور RODC ارسال می کند. در گام دوم سرور RODC به پایگاه داده خود که فایلی به نام NTDS.DIT است نگاه می کند تا ببیند آیا نام کاربری و رمز عبور کلاینت مورد نظر را بصورت ذخیره شده در پایگاه داده موجود دارد یا خیر ؟ با توجه به اینکه اطلاعات احراز هویت این کلاینت در پایگاه داده فعلی RODC قرار ندارد بنابراین RODC گام سوم را شروع می کند. در مرحله سوم RODC درخواست احراز هویت کلاین را از طریق لینک شبکه WAN به سمت سرور DC اصلی هدایت می کند و طبیعتا می داند که در آنجا باید اطلاعات در پایگاه داده وجود داشته باشد. در گام چهارم RWDC ما از پایگاه داده خود اطلاعات مربوط به احراز هویت را بررسی می کند و با توجه به اینکه در این قسمت اطلاعات در پایگاه داده وجود دارد در گام پنجم پاسخ را به سمت سرور RODC هدایت می کند که حاکی از صحت اطلاعات درخواستی احراز هویت می باشد. در گام ششم که مرحله بعدی است درخواست کلاینت سرویس دهی شده است و کلاینت می تواند در فایل سرور احراز هویت و Login کند اما طبیعتا از این موضوع خوشحال نیست که چرا خودش احراز هویت را انجام نداده است . برای اینکه مجددا شرمنده کلاینت ها نشود اینبار اطلاعات احراز هویتی کلاینت که کامپیوتر یا کاربر است در پایگاه داده RODC بصورت Cache شده نگهداری می شود تا در درخواست های احراز هویت بعدی کلاینت به جای سئوال کردن از سرور RWDC از اطلاعات خودش برای احراز هویت استفاده کند. برای اینکار ابتدا RWDC بررسی می کند که آیا Password Replication Policy خودش قابلیت Cache کردن پسوردها به RODC را داده است یا خیر ، اگر این اجازه داده شده بود ، اطلاعات احراز هویت آن کاربر در پایگاه داده RODC از این به بعد وجود خواهد داشت.

RODC چگونه کار می کند


خوب تا اینجای کار اگر مجددا کاربر یا کامپیوتر ما درخواست احراز هویت را به سمت RODC بفرستد ، فرآیند احراز هویت حتی با قطع شدن ارتباط شبکه WAN نیز انجام می شود و کاربر قادر به Login خواهد بود. اگر فرآیند Password Replication ای که عنوان کردیم در مرحله قبل انجام نمی شد RODC در صورت بروز مشکل برای لینک شبکه WAN دیگر قادر به احراز هویت نبود و درخواست کلاینت ما بی نتیجه می ماند. در مرحله بعدی می خواهیم در خصوص فرآیند دریافت Ticket و همچنین چگونگی دسترسی به سرویس مورد نظر صحبت کنیم. ITPRO باشید